For the load distribution of a server, a SLB (server load balancer) is used. The SLB distributes requests (messages) from a terminal device being a client to one of a plurality of servers according to an autonomous distribution algorithm, such as a round robin method or the like. A session being the unit of time information is exchanged is generated in a server by the distribution and a session ID (identification information) for uniquely identifying the session is reported to the terminal device via the SLB.
The SLB registers a relation between the session ID and a server storing a session having the ID in a distribution table. The terminal device requests by a message storing the session ID in its header. The SLB distributes the message to a server having the session by referring to the distribution table with the session ID stored in the header of the message. Thus, the SLB has a function to distribute messages from the same terminal device to the same server while the session continues. This function is called a uniqueness assurance function (or session maintenance function).
FIGS. 1 and 2 explain a method for realizing uniqueness assurance. FIG. 1 explains a method for realizing uniqueness assurance by SIP (session initiation protocol) used in the Internet telephone and the like. FIG. 2 explains a method for realizing uniqueness assurance by HTTP (hypertext transfer protocol) used for a Web server to transmit/receive data to/from a terminal device (browser).
A plurality of servers 1730 is virtually realized by an SLB 1720 and is accessed by a client 1710 being a terminal device as virtual servers. A request for a service using an SIP, from the client 1710 is transmitted by a message (packet) using the destination address of a transport header as the address of the virtual server. An identification call ID is stored in the SIP header of the message.
The destination address (Dst) of the transport header of the message transmitted from the client 1710 is converted to one address of the servers 1730 and distributed by the SLB 1720. An SIP session 1732 is generated in a server 1730 corresponding to the client 1710 by the distribution. The server 1730 generates a message storing the call ID assigned to the session 1732 in the SIP header and the address of its own server 1730 as the transmitting source address (Src) of a transport header and transmits the message to the SLB 1720 via an SIP I/F 1731.
The SLB 1720 registers the combination of the call ID and the address of the server 1730 in an SIP distribution table 1721, using the call ID as session identification information. The SLB 1720 converts the transmitting source address stored in the transport header of the message received from the server 1730 to the address of a virtual server and transmits the message to the SIP client 1710.
After that the client 1710 transmits a message storing a call ID in the SIP header and the address of the virtual server as the destination address of the transport header. The SLB 1720 refers to the distribution table 1721, specifies a server 1730 that is the transmitting destination of the message on the basis of the call ID in the SIP header and transfers the message to the specified server 1730. For the purpose of the transfer, the destination address of the transport header is converted to the address of the server 1730. The transmitting source address of the transport header of the message transmitted from the server 1730 is converted to the address of a virtual server. Thus, the SLB 1720 enables the same server 1730 to process the message transmitted from the client 1710 while the session 1723 is stored. As a result, uniqueness assurance can be realized.
Even a communication protocol changes from an SIP to an HTTP, as illustrated in FIG. 2, uniqueness assurance can be realized by the same method. In the HTTP, the message from the client 1710, distributed by the SLB 1720 is received by the HTTP I/F 1735 of the server 1730 and an HTTP session 1736 is generated. The server 1730 generates a message storing the session ID assigned to the session 1736 in the cookie of the HTTP header and transmits the message to the SLB 1720 via the I/F 1735.
The SLB 1720 registers the combination of the session ID and the address of the server 1730 in the HTTP distribution table 1722. The transmitting source address stored in the transport header of the message received from the server 1730 is converted to the address of a virtual server and is transmitted to the client 1710. Thus, after that, uniqueness assurance can be realized by referring to the distribution table 1722 and determining the transfer destination of the message received from the client 1710.
Both the combination of the call ID and the address of the server 1730 that is registered in the distribution table 1721 and the combination of the session ID and the address of the server 1730 that is registered in the distribution table 1722 are information for realizing uniqueness assurance. For that reason, hereinafter they are generally called “uniqueness assurance information”.
However, for example, in the field of the SDP (service discovery protocol) of an NGN (next generation network), a service obtained by combining a plurality of communication protocols which is generally called requestable application program (hereinafter called “connected application”) (an application program is briefly called “application” or “appli”) is provided. There are one capable of displaying call information via an HTTP after the call establishment of an SIP, one capable of performing the call control of an SIP via a Web page and the like in the connected application. As typical example of such a connected application, there is a CSBNA (Call Schedule on Busy or No Answer) application which can e an SIP and an HTTP.
In the connected application, in is necessary for a server in which a session is generated via a certain communication protocol to be also reached via another communication protocol in order to realize a connection among communication protocols. In other words, it is necessary to realize uniqueness assurance in order to connect communication protocols. However, the SLB selects a server to which a message is distributed for each communication protocol. Therefore, when connecting a plurality of communication protocols, uniqueness assurance cannot be supported by a plurality of communication protocols.
FIG. 3 is a conventional sequence chart illustrating the operations of a client, an SLB and a server in the case where load is distributed by the SLB arranged before a server group. This sequence chart indicates the case where although a client being a terminal device used by Alice requests for the start of communications with a client used by Bob using an SIP, the communications cannot be started and then the client used by Alice accesses a URL (uniform resource locator) using an HTTP. It is assumed that the communications is conducted via an SIP server 1730 being one server of the server group.
In FIG. 3 each of the clients used by Alice and Bob describes a logical entity for each communication protocol. A UA (user agent) for processing an SIP message, being one client is described as “ASU” (“Alice's SIP UA”) and “BSU” (“Bob's SIP UA”) in the client used by Alice and the client used by Bob, respectively. Reference numerals 1711 and 1713 are attached to ASU and BSU, respectively. A browser executed by the client of Alice is described as “AB” (“Alice's browser”) and a reference numeral 1712 is attached to it. When there is no need to refer to its logical entity, it is described as “client 1710” as described in FIGS. 1 and 2.
The SLB 1720 includes a transmission/reception identification unit 1725, an SIP processing unit 1726 and an HTTP processing unit 1727. The transmission/reception discrimination unit 1725 identifies communications with the client 1710 and a communication protocol on the basis of a message transmitted by the client 1710. The SIP processing unit 1726 processes a message (SIP message) transmitted by an SIP. The HTTP processing unit 1727 processes a message (HTTP message) transmitted by an HTTP.
The SIP server 1730 includes a CSBNA application (described in FIG. 3 as “CSBNA APPLI”) 1733 and a session (described in FIG. 3 as “APPLI SESSION #1”) 1732 generated in response to the request of the SIP UA 1711.
Firstly, the SIP UA 1711 performs a process in step SB41 according to the instruction of Alice and transmits an INVITE request to the SLB 1720 in order to start communications with Bob (sequence S2101). A call ID (described in FIG. 3 as “Call-ID#1”) by the SIP UA 1711 is stored in the SIP header of a message for the INVITE request. This INVITE request is identified an SIP message by the transmission/reception identification unit 1725 executing step SD41 and is transmitted to the SIP processing unit 1726 (sequence S2102). The SIP processing unit 1726 determines a distribution destination by executing step SE41 and transmits it to the SIP server 1730 (sequence S2103). In order to realize uniqueness assurance, it registers the combination of the call ID and the address of the distributed SIP server 1730 in the distribution table 1721 as uniqueness assurance information (sequence S2104).
The CSBNA application 1733 of the SIP server 1730 executes step SH41, determines a call ID to be used on the Bob side (call receiving side) and returns the INVITE request storing the call ID in the SIP header to the SLB 1720 (sequence S2105).
However, the CSBNA application 1733 generates a 100Trying response for notifying a calling party of being under processing and transmits it to the calling party (sequence S2131). This response is identified by the transmission/reception identification unit 1725 executing step SD43 and is transferred to the SIP processing unit 1726 (sequence S2132). The SIP processing unit 1726 transmits the 100Trying response to the client 1710 used by Alice by executing step SE43. As a result, the 100Trying response is processed by the SIP US 1711 executing step SB42.
The INVITE request transmitted from the SIP server 1730 is identified as an SIP message by the transmission/reception identification unit 1725 executing step SD42 and is transmitted to the SIP processing unit 1726 (sequence S2106). The SIP processing unit 1726 executes step SE 42 and registers the combination of the call ID and the address of the SIP server 1730 in the INVITE request in the distribution table 1721 as uniqueness information (sequence S2107). Then, it transmits the INVITE request to the client 1710 used by Bob (sequence S2108).
The INVITE request transmitted to the client 1710 used by Bob is processed by the SIP UA 1713 executing step SC41. In this case, a 486Busy response for notifying the transmitting source (Alice) of the fact that communications cannot be started for the reason that it is conducting other communications or the like is transmitted (sequence S2109).
The 486Busy response is identified by the transmission/reception identification unit 1725 of the SLB 1720 executing step SD44 and is transferred to the SIP processing unit 1726 (sequence S2110). The SIP processing unit 1726 refers to the distribution table 1721 using the call ID in the 486Busy response by executing step SE44 and specifies an SIP server 1730 to which this response should be distributed (sequence S2111). Thus, this response is transmitted to the specified SIP server 1730 (sequence S2112).
The CSBNA application 1733 of the SIP server 1730 executes step SH42 and processes the received 486Busy response. Thus, it generates a session 1732 (sequence S2113). In the session 1723, step SI41 is executed and its ID is returned (sequence S2114). The CSBNA application 1733 stores the calling party (SIP-URI (Uniform Resource Identifier) of Alice in this case) and the receiving party (SIP-URI of Bob in this case) as the data of the session 1732 (sequence S2116 and step SI42). Then, when the response is retuned from the session 1732 (sequence S2116), the obtained session ID is embedded in a URL for accessing via an HTTP and a 302 response (Redirect) describing the URL in its contact URI header is transmitted to the SLB 1720 (sequence S2117). When the 486Busy response is returned from the SIP UA 1713 of Bob, the 302 response is transmitted in order to urge the calling party to take other countermeasures.
This 302 response is identified by the transmission/reception identification unit 1725 executing step SD45 and is transferred to the SIP processing unit 1726 (sequence S2118). The SIP processing unit 1726 transmits the 302 response to the client 1710 used by Alice by executing step SE45 (sequence S2119). The 302 response transmitted to the client 1710 is processed by the SIP UA 1711 executing step SB43. Thus, the browser 1712 is activated (sequence S2120).
The activated browser 1712 transmits an HTTP GET request for accessing a URL described in the contact URI header of the 302 response by executing step SA41 (sequence S2121). This request is identified by the transmission/reception identification unit 1725 of the SLB 1720 executing step SD46 and is transferred to the HTTP processing unit 1727 (sequence S2122). The HTTP processing unit 1727 extracts the session ID from the URL specified by the HTTP GET request by executing step SF41 and refers to the distribution table 1722 (sequence S2123).
At the time of this reference, the HTTP GET request is the first HTTP message received from the client 1710 used by Alice. Therefore, the session ID extracted from the URL specified by the request is not registered in the distribution table 1722. Therefore, it is an autonomous distribution target. As a result, it cannot be assured that the HTTP GET request is distributed to the same SIP server 1730 as the SIP message.
When the HTTP message is distributed to a server 1730 different from the SIP server 1730 for distributing the SIP message, the session 1732 specified by the session ID included in the URL does not exist in the different server 1730. Thus, an error occurs and the process cannot be continued. Therefore, even when load is distributed among a plurality of servers, it is important to take into consideration the uniqueness assurance of connections among a plurality of communication protocols.
It is common to delete a session generated in a server on a condition that no request for it is received from a terminal device for a certain time. This is mainly because the waste of resources due to the existence of an unnecessary session or a session having a high possibility of being unnecessary.
The time set as a condition for deleting a session (hereinafter called “timeout time”) is determined taking various states into consideration. However, sometimes there is a fairly long time until a server receives a request after it is transmitted from a terminal device, depending on the traffic of a communication network connecting the terminal device and the SLB, the load state of an SLB and the like. In that case, there is a possibility that although a request is transmitted from the terminal with timing the session is essentially deleted (timing no timeout occurs), the server deletes the session.
When the server receives the request after deleting the session too, an error occurs. It is preferable to suppress the frequency of an error process in order to reduce the load of a server. However, even when a request is transmitted from a terminal device with timing no timeout occurs, sometime timeout occurs due to the increase of transmission time by the traffic in a communication network (telecommunication line) or the like. Therefore, in the realization of uniqueness assurance, it is also important to appropriately cope with the increase of a transmission time in order to suppress the load of a server.
As technical reference literatures, there are Japanese Laid-open Patent Publication Nos. 2004-247916 and 2005-318439, Japanese Patent No. 3963690 and Dynamicsoft Inc., “SIP Servlet API, Version 1.0” (Feb. 4, 2003).